PowerCLI включает в себя 3 функции для управления настройкой NTP серверa: Get/Add/Remove-VMHostNtpServer. Это можно видеть с помощью Get-Command. На мой взгляд явно не хватает ещё одной - Set-VMHostNtpServer. Данная функция объединяет в себе все 3 предыдущих плюс ещё пару для рестарта NTP-сервиса для применения конфигурации. Просто скачайте мой PowerCLI-модуль для управления виртуальной инфраструктурой VMware Vi-Module.psm1 и импортируйте его.
Интересный пост вышел на одном из блогов компании VMware о производительности протокола VMware Horizon Blast Extreme, который используется совместно с технологией построения инфраструктуры производительных виртуальных десктопов NVIDIA GRID.
Не так давно мы писали о новых возможностях VMware Horizon 7, одной из которых стало полноценное включение протокола Blast Extreme на основе видеокодека H.264 в стек используемых протоколов наряду с PCoIP и RDP. Совместно с решением NVIDIA GRID производительность протокола Blast Extreme значительно возрастает, давайте посмотрим насколько.
В тесте команды NVIDIA GRID Performance Engineering Team использовался симулятор рабочей нагрузки ESRI ArcGIS Pro 1.1, который воспроизводил типичные действия пользователей а в качестве основных метрик снимались задержки (latency), фреймрейт (FPS), требуемая полоса пропускания (bandwidth) и прочие. При этом проводилось сравнение Blast Extreme (в программном варианте и при аппаратном ускорении GRID) с протоколом PCoIP, который широко используется в настоящий момент.
Благодаря ускорению обработки кодирования/декодирования на аппаратном уровне, уменьшаются задержки при выполнении операций (за счет ускорения обработки на стороне сервера):
Blast Extreme уменьшает задержку аж на 51 миллисекунду по сравнению с традиционным PCoIP.
По результатам теста для FPS производительность Blast Extreme превосходит PCoIP на целых 37%:
Для 19 виртуальных машин на одном сервере в тесте ESRI ArcGIS Pro 1.1 необходимая полоса пропускания для Blast Extreme была ниже на 19%, чем для PCoIP (и это без потерь качества картинки):
Благодаря кодеку H.264, который передает нагрузку на сторону выделенных аппаратных движков NVIDIA GPU, снижается нагрузка на центральный процессор хост-сервера VMware ESXi на 16%:
При этом удалось добиться увеличения числа пользователей на сервере ESXi на 18%, а это 3 человека на сервер.
Понятно, что тест ESRI ArcGIS Pro 1.1 не является универсальной нагрузкой, но в целом можно сказать, что Blast Extreme при аппаратном ускорении повышает производительность процентов на 15.
В этот раз мы рассмотрим сразу две функции Enable-VMHostSSH/Disable-VMHostSSH моего PowerCLI модуля для управления виртуальной инфраструктурой VMware Vi-Module.psm1. Очень часто администраторам виртуальной инфраструктуры требуется временно включить SSH на хосте/хостах ESXi, например, для запуска esxtop или для выяснения причин PSOD или для решения проблем с СХД...
Какое-то время назад мы писали о функции Data Locality, которая есть в решении для создания отказоустойчивых кластеров VMware Virtual SAN. Каждый раз, когда виртуальная машина читает данные с хранилища, они сохраняются в кэше (Read Cache) на SSD-накопителе, и эти данные могут быть востребованы очень быстро. Но в рамках растянутого кластера (vSphere Stretched Cluster) с высокой скоростью доступа к данным по сети передачи данных, возможно, фича Site / Data Locality вам не понадобится. Вот по какой причине.
Если ваши виртуальные машины часто переезжают с хоста на хост ESXi, при этом сами хосты географически разнесены в рамках VSAN Fault Domains, например, по одному зданию географически, то срабатывает функция Site Locality, которая требует, чтобы кэш на чтение располагался на том же узле/сайте, что и сами дисковые объекты машины. Это отнимает время на прогрев кэша хоста ESXi на новом месте для машины, а вот в скорости в итоге особой прибавки не дает, особенно, если у вас высокоскоростное соединение для всех серверов в рамках здания.
В этом случае Site Locality лучше отключить и не прогревать кэш каждый раз при миграциях в рамкха растянутого кластера с высокой пропускной способностью сети. Сначала запросим значение Site Locality:
Очередная функция Compare-VMHostSoftwareVibмоего PowerCLI-модуля для управления виртуальной инфраструктурой VMware Vi-Module.psm1 поможет вам сравнить установленные VIB-пакеты (vSphere Installation Bundle) между двумя и более хостами ESXi. Функция позволяет сравнивать как два отдельно взятых хоста, так и группу хостов, например, сравнить целый HA/DRS Cluster с эталонным хостом.
Компания VMware выпустила очень интересный документ "VMware vSphere 6
Fault Tolerance
Architecture and Performance", посвященный производительности технологии VMware Fault Tolerance (FT), которая позволяет обеспечивать непрерывную доступность виртуальных машин, даже в случае отказа хост-сервера VMware ESXi. Делается это за счет техники Fast Checkpointing, по своей сути похожей на комбинацию Storage vMotion и vMotion, которая копирует состояние дисков, памяти, процессорных команд и сетевого трафика на резервную машину, поддерживая ее в полностью синхронизированном с первой состоянии. На данный момент vSphere 6 FT поддерживает виртуальные машины с конфигурацией до 4 vCPU и до 64 ГБ оперативной памяти на хост ESXi.
Давайте посмотрим на интереснейшие результаты тестирования производительности, приведенные в документе.
1. Процедура компиляции ядра в гостевой ОС.
Эта процедура грузит CPU на 100%, поэтому посмотрим, каковы тут потери, связанные с аспектами производительности процессора и синхронной передачи команд. Все вполне хорошо, потери небольшие:
2. Сетевая активность.
Если говорить о производительности сетевой коммуникации, то на получение данных потерь практически нет, а вот на передачу все происходит процентов на 10 медленнее. Результат для 1 Гбит сети:
Кстати, очевидно, что сетевой трафик именно самой сети FT максимальный, когда машина принимает много данных (их нужно синхронизировать на второй узел), когда же данные передаются там трафик намного меньше (машина их просто отдает, а синхронизировать нужно только сам процесс передачи и параметры канала).
Результат для 10 Гбит сети. Вот тут и происходит ситуация, когда канал на прием забивается FT-трафиком, как итог - прием происходит только на полосе 2,4 Гбит:
Из-за необходимости поддержки параметров сетевой передачи и приема в синхронном режиме возникает Latency около 6 миллисекунд:
3. Тестирование подсистемы ввода-вывода.
Для тестирования работы с хранилищами (I/O) взяли стандартный инструмент IOMeter. Особых потерь не обнаружилось:
4. Тест Swingbench для Oracle 11g.
Для теста была взята OLTP-нагрузка на базу данных. По числу транзакций в секунду потери небольшие, но задержка по времени ответа возникает значительная:
5. Тест DVD Store на Microsoft SQL Server 2012.
Здесь была запущена симуляция 64 пользовательских сессий. По-сути, этот тест очень похож на методику для Oracle, ну и результаты здесь также соответствующие (но по времени отклика как-то все очень печально):
6. Бенчмарк на базе TPC-E.
Здесь были симулированы операции сервера брокерской компании, который производит обработку OLTP-транзакций в реальном времени. Тест очень стрессовый, и потери здесь весьма существенны:
7. Операции VMware vCenter Server.
Ну а здесь уже сам сервер vCenter защитили технологией Fault Tolerance и измерили производительность операций для двух типов нагрузки - легкой и тяжелой. При тяжелой нагрузке все происходит медленнее больше чем в 2 раза:
vSphere Web Client работает, в общем-то, неплохо, но хотелось бы лучше:
Результаты тестирования очень полезны - теперь администраторы смогут закладывать потери производительности на поддержание FT-кластера в архитектуру планируемой инфраструктуры для бизнес-критичных приложений.
Когда вы ставите один сервер VMware ESXi, то проще всего сделать это, смонтировав ISO-образ через iLO или подобную консоль, либо воткнув загрузочную флешку непосредственно в сервер. Но если у вас несколько хост-серверов ESXi, то делать так уже несолидно для опытного администратора. В целях ускорения процесса он использует процедуру загрузки установщика хоста по сети через механизм PXE, а самые крутые администраторы уже используют средство Auto Deploy, у которого сравнительно недавно появился GUI.
На эту тему компания VMware выпустила очень полезный документ "Installing ESXi Using PXE", в котором эта процедура расписывается по шагам (как для BIOS, так и для UEFI-хостов):
Интересна диаграмма зрелости процесса установки VMware ESXi в организации. Новички прожигают исошку на диск, а крутые перцы - используют Auto Deploy для stateless-хостов:
А вот, например, основная диаграмма последовательности процессов при установке ESXi через PXE:
По шагам процедура выглядит так:
1. Администратор загружает целевой хост ESXi.
2. Этот хост делает DHCP-запрос.
3. DHCP-сервер отвечает с IP-параметрами и расположением TFTP-сервера, который содержит загрузчик.
4. ESXi обращается к серверу TFTP и запрашивает файл загрузчика, который указал DHCP-сервер.
5. TFTP-сервер посылает загрузчик хосту ESXi, который исполняет его. Начальный загрузчик догружает дополнительные компоненты с TFTP-сервера.
6. Загрузчик ищет конфигурационный файл на TFTP-сервере, скачивает ядро и другие компоненты ESXi с HTTP-сервера, который размещен на TFTP-сервере, и запускает ядро на хосте ESXi.
7. Установщик ESXi запускается в интерактивном режиме, либо используя kickstart-скрипт, который указан в конфигурационном файле.
Для автоматизации задач по подготовке ISO-образа ESXi к загрузке через PXE вы можете использовать вот этот полезный скрипт.
Таги: VMware, ESXi, PXE, Boot, Auto Deploy, Whitepaper, vSphere
Вчера мы писали про режим воспроизведения, который можно использовать для утилиты esxtop, предназначенной мониторинга производительности хост-серверов VMware ESXi. А сегодня предлагаем вам скачать постер "vSphere 6 ESXTOP quick Overview for Troubleshooting", в котором приведена основная информация для начала работы с esxtop, а также базовые приемы по решению возникающих в виртуальной инфраструктуре проблем с производительностью. Также стоит заглянуть вот в эту и эту заметку на нашем сайте.
Постер можно повесить в админской или серверной, где часто приходится работать с консолью серверов ESXi:
Мы часто пишем о том, что снапшоты в VMware vSphere - это плохо (за исключением случаев, когда они используются для горячего резервного копирования виртуальных машин и временного сохранения конфигурации ВМ перед обновлением).
Однако их использование в крупных инфраструктурах неизбежно. Рано или поздно возникает необходимость удаления/консолидации снапшотов виртуальной машины (кнопка Delete All в Snapshot Manager), а процесс этот достаточно длительный и требовательный к производительности хранилищ, поэтому неплохо бы заранее знать, сколько он займет.
Напомним, что инициирование удаления снапшотов в vSphere Client через функцию Delete All приводит к их удалению из GUI сразу же, но на хранилище процесс идет долгое время. Но если в процесс удаления возникнет ошибка, то файлы снапшотов могут остаться на хранилище. Тогда нужно воспользоваться функцией консолидации снапшотов (пункт контекстного меню Consolidate):
О процессе консолидации снапшотов мы также писали вот тут. Удаление снапшотов (как по кнопке Delete All, так и через функцию Consolidate) называется консолидацией.
Сначала посмотрим, какие факторы влияют на время процесса консолидации снапшотов виртуальной машины:
Размер дельта-дисков - самый важный параметр, это очевидно. Чем больше данных в дельта-диске, тем дольше их нужно применять к основному (базовому) диску.
Количество снапшотов (число дельта-файлов) и их размеры. Чем больше снапшотов, тем больше метаданных для анализа перед консолидацией. Кроме того, при нескольких снапшотах консолидация происходит в несколько этапов.
Производительность подсистемы хранения, включая FC-фабрику, Storage Processor'ы хранилищ, LUN'ы (число дисков в группе, тип RAID и многое другое).
Тип данных в файлах снапшотов (нули или случайные данные).
Нагрузка на хост-сервер ESXi при снятии снапшота.
Нагрузка виртуальной машины на подсистему хранения в процессе консолидации. Например, почтовый сервер, работающий на полную мощность, может очень долго находится в процессе консолидации снапшотов.
Тут надо отметить, что процесс консолидации - это очень требовательный к подсистеме ввода-вывода процесс, поэтому не рекомендуется делать это в рабочие часы, когда производственные виртуальные машины нагружены.
Итак, как можно оценивать производительность процесса консолидации снапшотов:
Смотрим на производительность ввода-вывода хранилища, где находится ВМ со снапшотами.
Для реализации этого способа нужно, чтобы на хранилище осталась только одна тестовая виртуальная машина со снапшотами. С помощью vMotion/Storage vMotion остальные машины можно с него временно убрать.
1. Сначала смотрим размер файлов снапшотов через Datastore Browser или с помощью следующей команды:
ls -lh /vmfs/volumes/DATASTORE_NAME/VM_NAME | grep -E "delta|sparse"
2. Суммируем размер файлов снапшотов и записываем. Далее находим LUN, где размещена наша виртуальная машина, которую мы будем тестировать (подробнее об этом тут).
3. Запускаем команду мониторинга производительности:
# esxtop
4. Нажимаем клавишу <u> для переключения в представление производительности дисковых устройств. Для просмотра полного имени устройства нажмите Shift + L и введите 36.
5. Найдите устройство, на котором размещен датастор с виртуальной машиной и отслеживайте параметры в колонках MBREAD/s и MBWRTN/s в процессе консолидации снапшотов. Для того, чтобы нужное устройство было вверху экрана, можно отсортировать вывод по параметру MBREAD/s (нажмите клавишу R) or MBWRTN/s (нажмите T).
Таким образом, зная ваши параметры производительности чтения/записи, а также размер снапшотов и время консолидации тестового примера - вы сможете оценить время консолидации снапшотов для других виртуальных машин (правда, только примерно того же профиля нагрузки на дисковую подсистему).
Смотрим на производительность конкретного процесса консолидации снапшотов.
Это более тонкий процесс, который можно использовать для оценки времени снапшота путем мониторинга самого процесса vmx, реализующего операции со снапшотом в памяти сервера.
1. Запускаем команду мониторинга производительности:
# esxtop
2. Нажимаем Shift + V, чтобы увидеть только запущенные виртуальные машины.
3. Находим ВМ, на которой идет консолидация.
4. Нажимаем клавишу <e> для раскрытия списка.
5. Вводим Group World ID (это значение в колонке GID).
6. Запоминаем World ID (для ESXi 5.x процесс называется vmx-SnapshotVMX, для ранних версий SnapshotVMXCombiner).
7. Нажимаем <u> для отображения статистики дискового устройства.
8. Нажимаем <e>, чтобы раскрыть список и ввести устройство, на которое пишет процесс консолидации VMX. Что-то вроде naa.xxx.
9. Смотрим за процессом по World ID из пункта 6. Можно сортировать вывод по параметрам MBREAD/s (клавиша R) или MBWRTN/s (клавиша T).
10. Отслеживаем среднее значение в колонке MBWRTN/s.
Это более точный метод оценки и его можно использовать даже при незначительной нагрузке на хранилище от других виртуальных машин.
Очередная функция Get-VMHostFirmwareVersion моего PowerCLI модуля для управления виртуальной инфраструктурой VMware Vi-Module.psm1 поможет вам узнать версию и дату выпуска Firmware ваших серверов ESXi. Для большей гибкости и удобства в использовании, функция написана в виде PowerShell-фильтра.
Это гостевой пост сервис-провайдера 1cloud, предоставляющего услуги облачной аренды виртуальных машин. Ранее они рассказывали о развитии данной технологии в статье о «революции контейнеров» в своем блоге на Хабре.
Шумиха вокруг контейнеров последнего времени поставила один важный вопрос: как эта технология сможет ужиться с традиционными вариантами управления инфраструктурой, и какие угрозы она таит для рынка виртуализации? И даже более конкретный: заменят ли контейнеры виртуальные машины?
На ежегодной конференции в Сан-Франциско, прошедшей на в сентябре 2015 года, VMware дала однозначно понять, что этого не произойдет. Новая платформа управления вводит новый тип виртуализации — для самих контейнеров.
Виртуализация для контейнеров
Полтора десятка лет назад VMware взорвала технологическую индустрию, выпустив свой корпоративный гипервизор, открывший эпоху серверной виртуализации. На прошлой неделе компания представила обновленную версию своей классической программы для виртуализации под названием Project Photon. По сути, это облегченная реплика популярного гипервизора ESX компании, разработанная специально для работы с приложениями в контейнерной реализации.
«В ее основе, по-прежнему, лежит принцип виртуализации», — объясняет вице-президент VMware и технический директор Cloud Native Applications Кит Колберт. Он предпочитает называть Photon «микровизором» с достаточным набором функций для успешной виртуализации, упакованный в удобный для контейнеров формат.
Project Photon состоит из двух ключевых элементов. Photon Machine – оболочка для гипервизора, дублирующая ESX и устанавливаемая напрямую на физические серверы. Она создает виртуальную машину в миниатюре, куда помещаются контейнеры. Пользователь может самостоятельно выбрать гостевую ОС. По умолчанию устанавливается Photon ОС под Linux, которую компания также сделала совместимой с технологией контейнеров.
Второй элемент – это Photon Controller, мультитенантный маршрутизатор, позволяющий управлять одновременно дюжинами, если не тысячами, объектов на Photon Machine. Он следит за тем, чтобы все блоки (кластеры) Photon Machine имели доступ к сети и базам данных, когда это необходимо.
Комбинация этих двух элементов задает шаблон для масштабируемой среды и имеет надстройку для написания API. В теории, IT-операторы могу усовершенствовать Project Photon, и сами разработчики создавать на его базе приложения.
Project Photon способен интегрироваться с открытыми программами. Например, с Docker’ом для поддержки исполнения программы, или с Google Kubernetes и Pivotil’s Cloud Foundry для более качественного управления приложениями. Photon в данном случае выполняет подготовку инфраструктуры, а Kubernetes и CF занимаются развертыванием приложений.
В прошлом году для индивидуальных пользователей платформа стала доступна в качестве бета-версии.
Долгая дорога к контейнерам
Не все пользователи готовы полностью переключиться на контейнерную реализацию. Поэтому VMware для сомневающихся интегрирует поддержку контейнеров с традиционными инструментами управления.
vSphere Integrated Containers – еще один продукт, анонсированный на конференции. Как пояснил Кит Колберт, это идеальный вариант для тех, кто только хочет начать экспериментировать с контейнерами. Для желающих же использовать возможности контейнеров по максимуму он рекомендует переход к Project Photon.
vSphere Integrated Containers представляет собой плагин для vSphere, установленной на достопочтенном ESX компании. «Он делает контейнеры самыми желанными гостями платформы», — уточняет Колберт. При помощи плагина пользователи могут устанавливать контейнеры внутрь виртуальной машины, позволяя управлять ею так же, как и любой другой в пространстве платформы виртуализации.
В текущих условиях, если пользователь решил загрузить контейнеры в vSphere, ему приходится все скопом помещать их в одну единственную виртуальную машину. Таким образом, если что-то случится с одним из контейнеров, повреждения могут получить и все остальные, находящиеся в ВМ. Распределение контейнеров по разным ВМ обеспечивает их сохранность и аккуратное управление платформой.
Аналитик Marko Insights Курт Марко говорит, что новый подход к контейнерной реализации VMware должен облегчить жизнь и самим администраторам платформы. «Работа с контейнерами Photon в формате микро-ВМ схожа с тем, как работают с классом стеков и операторов, — сообщает Марко в своем письме. – Конечно, здесь могут быть потери в производительности, поскольку даже микро-ВМ будут больше перегружены, чем контейнеры, пользующиеся одними ядрами и библиотеками. В самой VMware утверждает, что это проблемой можно пренебречь, но Марко настаивает на независимом анализе издержек работы с контейнерами внутри виртуальных машин.
Не все так быстро
В VMware полны энтузиазма и рассматривают себя в качестве флагмана контейнерной реализации. Но есть несколько моментов, способных этот порыв охладить. Во-первых, вероятно, рынок контейнеров еще к этому не готов.
«Реклама продукта пока обгоняет реальность», — говорит аналитик IDC Эл Гиллен. По его подсчетам, менее десятой доли процента корпоративных приложений сейчас делаются через контейнеры. Может пройти десятилетие, пока рынок переварит эти технологии, и цифра приблизится к 40%.
Во-вторых, VMware никогда не обладала репутацией компании, готовой быть в авангарде разработок открытого программного обеспечения и проектов. Скорее, наоборот. Соучредитель и исполнительный директор Rancher Labs (стартапа, внедрившего свою ОС для контейнеров на VMworld) Шен Льян говорит, что до этого момента контейнерную реализацию продвигали сами разработчики или открытые платформы, наподобие Mesos, Docker и Kubernetes. Он добавил, что не встречал еще ни одного человека, использующего в работе контейнеры, который бы делал это с помощью инструментария VMware.
Аналитик Forrester Дейв Бартолти не удивлен данному обстоятельству. В VMware налажены прочные связи с проектными ИТ-менеджерами, но не с разработчиками, активно использующими контейнеры. Новинки, которые компания представила на VMworld, должны как раз вдохновить первых активно использовать контейнеры в рамках работы с платформой VMware. Остальные вендоры, среди которых Red Hat, Microsoft и IBM, также с удовольствием пользуются этой процедурой. VMware настаивает, что нашла способ примерить виртуальные машины и контейнеры.
В новой книге Фрэнка на 300 страницах раскрываются следующие моменты, касающиеся производительности подсистемы хранения платформ виртуализации, построенной на базе локальных дисков хост-серверов:
Новая парадигма построения виртуального датацентра с точки зрения систем хранения
Архитектура решения FVP
Ускорение доступа к данным
Технология непрерывной доступности Fault Tolerance
Технология Flash
Техники доступа к памяти
Настройка кластера решения FVP
Сетевой дизайн инфраструктуры локальных хранилищ
Внедрение и пробная версия решения FVP
Дизайн инфраструктуры хранилищ
Несмотря на то, что книга рассматривает в качестве основного продукта решение FVP от компании PernixData, ее интересно читать и с точки зрения понимания архитектуры и производительности подобных решений.
Какое-то время назад мы писали о технологии доставки приложений пользователям инфраструктуры настольных ПК предприятия - VMware App Volumes (ранее это называлось Cloud Volumes). Суть ее заключается в том, что виртуализованные и готовые к использованию приложения VMware ThinApp доставляются пользователям в виде подключаемых виртуальных дисков к машинам.
Недавно компания VMware выпустила документ "VMware App Volumes Reference Architecture", в котором объясняется работа технологии App Volumes, рассматривается референсная архитектура этого решения, а также проводится тестирование производительности доставляемых таким образом приложений по сравнению с их нативной установкой внутри виртуальных ПК:
Собственно, типовая архитектура решения App Volumes выглядит следующим образом:
Здесь показаны основные компоненты такой инфраструктуры:
AppStacks - это тома, которые содержат сами установленные приложения и работают в режиме Read Only. Их можно назначить пользователям Active Directory, группам или OU. Один такой диск может быть назначен сразу нескольким виртуальным ПК (по умолчанию доступен всем машинам датацентра).
Writable Volumes - это персонализированные тома, которые принадлежат пользователям. Они хранят настройки приложений, лицензионную информацию, файлы конфигураций приложений и сами приложения, которые пользователь установил самостоятельно. Один такой диск может быть назначен только одному десктопу, но его можно перемещать между десктопами.
App Volumes Manager Server - это Windows-сервер, содержащий административную консоль для настройки продукта и управления им.
В качестве референсной архитектуры используется инфраструктура из 2000 виртуальных ПК, запущенных на 18 хостах ESXi инфраструктуры VMware Horizon View:
Для генерации нагрузки использовались различные сценарии пользовательского поведения, создаваемые с помощью средства Login VSI, ставшего уже стандартом де-факто для тестирования VDI-инфраструктур, развернутого на трех хост-серверах.
Здесь описаны 3 варианта тестирования:
Приложения, нативно установленные в виртуальных ПК.
Приложения App Volumes, использующие один AppStack, содержащий основные приложения пользователей.
Приложения App Volumes, распределенные по трем различным AppStack.
Для обоих случаев тестирования App Volumes использовался один Writable Volume. Тут были получены следующие результаты (больше очков - это лучше).
Посмотрим на время логина пользователей при увеличении числа одновременных сессий в референсной архитектуре:
Взглянем на время отклика приложений:
Оценим время запуска приложений:
В целом-то, нельзя сказать, что потери производительности незначительные - они, безусловно, чувствуются. Но радует, что они фиксированы и хорошо масштабируются при увеличении числа одновременных сессий в VDI-инфраструктуре.
Документ очень полезен для оценки потерь производительности с точки зрения User Experience при использовании App Volumes по сравнению с традиционной доставкой приложений. Скачать 50-страничный документ можно скачать по этой ссылке - почитайте, там действительно интересно все изложено.
Пару месяцев назад мы писали о том, что вышло обновление VMware vSphere 5.5 Update 3, которое полезно для пользователей, еще не перешедших на обновленную версию платформы виртуализации vSphere 6.
Новых возможностей там было немного, поэтому многие проигнорировали этот апдейт - а зря. Там появилось множество улучшений производительности операций в Web Client, о чем у VMware есть отдельная статья. Приведем основную выжимку здесь.
Как вы знаете, в vSphere Web Client 6.0 был сделан шаг вперед в плане улучшения производительности, а сейчас инженеры VMware портировали эти изменения уже на младшую версию vSphere 5.5 U3. При этом, по оценке самой VMware, теперь производительность тонкого клиента в этой версии в некоторых аспектах аналогична оной в vSphere 6.0 Update 1.
Улучшения были сделаны в следующих областях:
Меню действий и меню по правому клику мыши
Страницы Related Objects, Summary и Settings
Мастера выполнения операций (миграция, создание шаблона и т.п.)
Процесс логина в консоль
Графики отображения производительности
Для тестирования сделанных улучшений (VMware уверяет, что их было сделано очень много) использовались 2 типа окружения:
Большое – vCenter Server (32 vCPU / 64 GB RAM), 1000 хостов, 15000 ВМ
Посмотрим на время логина в Web Client:
Уменьшилось ровно в 2 раза. Теперь посмотрим на отклик меню действий (оно же вызывается по правой кнопке мыши):
Здесь кое-где и в 3 раза улучшилась ситуация. Для меню виртуальных машин ситуация не сильно улучшилась, так как в этом меню большое количество контекстно-зависимых действий.
Генерация графиков производительности (выбор объектов, ресайз графиков, обновление, выбор элементов для отображения). Здесь очень существенные улучшения, более чем в 2 раза:
Отображение связанных объектов, например, вы выбираете кластер и отображения списка виртуальных машин в нем происходит намного быстрее:
В общем, если вы еще не обновились - причина поставить новую версию Web Client есть.
Таги: VMware, Web Client, Performance, Update, vSphere
Многие из вас знают, что в решении VMware Horizon View есть две полезных возможности, касающихся функций печати из виртуального ПК пользователя - это перенаправление принтеров (Printer redirection) и печать на основе местоположения (Location based printing). Об этих функциях подробно рассказано в документе "Virtual Printing Solutions with View in Horizon 6", а мы изложим тут лишь основные сведения, содержащиеся в нем.
Printer redirection
Эта возможность позволяет перенаправить печать из виртуального ПК к локальному устройству пользователя, с которого он работает, и к которому подключен принтер уже физически. Функция поддерживается не только для Windows-машин, но и для ПК с ОС Linux и Mac OS X. Работает эта фича как для обычных компьютеров, так и для тонких клиентов (поддерживается большинство современных принтеров).
При печати пользователь видит принтер хоста не только в диалоге печати приложения, но и в панели управления. При этом не требуется в виртуальном ПК иметь драйвер принтера - достаточно, чтобы он был установлен на хостовом устройстве.
Перенаправление принтеров полезно в следующих случаях:
в общем случае, когда к физическому ПК пользователя привязан принтер
когда пользователь работает из дома со своим десктопом и хочет что-то распечатать на домашнем принтере
работники филиала печатают на локальных принтерах, в то время, как сами десктопы расположены в датацентре центрального офиса
Схема передачи задания на печать для перенаправления принтера выглядит так:
То есть Horizon Client получает данные в формате EMF от виртуального ПК и передает его уже на хостовом устройстве к драйверу принтера.
Location based printing
Эта фича позволяет пользователям виртуальных ПК печатать на тех принтерах, которые находятся географически ближе к нему, чтобы не бегать, например, на другой этаж офисного здания, чтобы забирать распечатанное, когда есть принтеры поблизости. Правила такой печати определяются системным администратором.
Для функции Location based printing задания печати направляются с виртуального ПК напрямую на принтер, а значит нужно, чтобы на виртуальном десктопе был установлен драйвер этого принтера.
Есть 2 типа правил Location based printing:
IP-based printing - используется IP-адрес принтера для определения правил маппинга принтера к десктопам.
UNC-based printing - используются пути в формате Universal Naming Convention (UNC) для определения правил маппинга принтеров.
Здесь задание на печать передается в рамках следующего рабочего процесса:
Запрос пользователя с хостового устройства через Horizon Client передается к View Agent, который через взаимодействие с приложением передает задание драйверу принтера в гостевой ОС с учетом правил маппинга принтеров, а дальше уже обработанное задание идет на печать.
В зависимости от способа доступа, поддерживаются методы перенаправления принтеров или печать на основе местоположения:
Очевидно, что в нулевом клиенте и в мобильном девайсе нет хостового драйвера принтера, поэтому там и нет поддержки Printer redirection. Ну и то же самое можно сказать про доступ HTML access через браузер - там тоже поддержка отсутствует.
Надо сказать, что и Printer redirection, и Location based printing поддерживаются для следующих моделей доступа пользователей инфраструктуры VDI:
Десктопы View
Десктопы RDSH
Десктопы Windows Server 2008 R2 и Windows Server 2012 R2
Приложения Hosted apps
Ну а о том, как настраивать обе техники печати из виртуальных ПК вы можете прочитать в документе.
Представляем гостевой пост компании 1cloud, предоставляющей услуги в области хостинга виртуальных машин по модели IaaS. С падением цен на SSD все больше компаний предлагают массивы, целиком построенные на флеш-памяти, но действительно ли они лучше гибридных массивов, содержащих как твердотельные накопители, так и жесткие диски?
Те, из вас, кто пользуется веб-средством vSphere Web Client для управления виртуальной инфраструктурой VMware vSphere, знают, что при логине в окно клиента в самом низу предлагают скачать Client Integration Plugin (CIP):
CIP - это пакет средств от VMware, представляющий собой набор полезных утилит для некоторых административных операций в виртуальной инфраструктуре. Утилиты доступны как для Microsoft Windows, так и для Apple Mac OS X (а скоро будет и поддержка Linux).
Посмотрим на состав этого набора:
ovftool - это отдельная утилита CLI, которую можно использовать для импорта и экспорта виртуальных модулей (Virtual Appliances) в форматах OVF и OVA.
Windows Authentication - позволяет использовать аутентификацию SSPI Windows при логине через vSphere Web Client.
Remote Devices - возможность подключить клиентские устройства (CD-ROM, Floppy, USB и прочие) к виртуальной машине.
File Upload/Download - это вынесенный в отдельную утилиту Datastore browser для загрузки файлов на виртуальные хранилища.
Content Library - операции импорта и экспорта для компонента Content Library.
Client Side Logging/Config - позволяет записывать логи на стороне клиента, а также реализует настройки логирования vSphere Web Client.
Процедура развертывания vSphere Client Integration Plugin выглядит примерно так (видео от версии vSphere 5.5):
Ранее CIP как браузерный плагин использовал модель Netscape Plugin Application Programming Interface (NPAPI), но поскольку в Google Chrome последних версий и прочих браузерах поддержка этой устаревшей модели была окончена, то теперь используется обновленная модель отображения, которая реализована, начиная с Sphere 5.5 Update 3a и vSphere 6.0 Update 1 (поэтому лучше CIP использовать с платформами этих версий или выше).
Более подробно об утилитах CIP рассказано вот тут.
На блогах VMware появился интересный пост про производительность виртуальных машин, которые "растянуты" по ресурсам на весь физический сервер, на котором они запущены. В частности, в посте речь идет о сервере баз данных, от которого требуется максимальная производительность в числе транзакций в секунду (см. наш похожий пост о производительности облачного MS SQL здесь).
В данном случае речь идет о виртуализации БД с типом нагрузки OLTP, то есть обработка небольших транзакций в реальном времени. Для тестирования использовался профиль Order-Entry, который основан на базе бенчмарка TPC-C. Результаты подробно описаны в открытом документе "Virtualizing Performance Critical Database Applications in VMware vSphere 6.0", а здесь мы приведем основные выдержки.
Сводная таблица потерь на виртуализацию:
Метрика
Нативное исполнение нагрузки
Виртуальная машина
Пропускная способность транзакций в секунду
66.5K
59.5K
Средняя загрузка логических процессоров (72 штуки)
84.7%
85.1%
Число операций ввода-вывода (Disk IOPS)
173K
155K
Пропускная способность ввода-вывода дисковой подсистемы (Disk Megabytes/second)
929MB/s
831MB/s
Передача пакетов по сети в секунду
71K/s receive
71K/s send
63K/s receive
64K/s send
Пропускная способность сети в секунду
15MB/s receive
36MB/s send
13MB/s receive
32MB/s send
А вот так выглядит график итогового тестирования (кликабельно):
Для платформы VMware ESXi 5.1 сравнивалась производительность на процессоре микроархитектуры Westmere, а для ESXi 6.0 - на процессорах Haswell.
Результаты, выраженные в числе транзакций в секунду, вы видите на картинке. Интересно заметить, что ESXi версии 6.0 всерьез прибавил по сравнению с прошлой версией в плане уменьшения потерь на накладные расходы на виртуализацию.
А вот так выглядят усредненные значения для версий ESXi в сравнении друг с другом по отношению к запуску нагрузки на нативной платформе:
Ну и несложно догадаться, что исследуемая база данных - это Oracle. Остальное читайте в интереснейшем документе.
Horizon Toolbox 2 - это дополнение к стандартной консоли View Administrator, исполненное в виде веб-портала с различными функциями вроде аудита, удаленной поддержки и прочих полезных возможностей:
Перечислим основные нововведения VMware View Horizon Toolbox 2:
1. Console Access
Теперь появилась возможность полноценного доступа к консоли виртуальных ПК:
Можно просматривать список виртуальных машин для пулов виртуальных ПК и фильтровать их по именам машин (или DNS-именам).
2. Power-on policy
Теперь появилась вкладка Power-on policy, на которой можно посмотреть и изменить политику включения рабочих виртуальных ПК по дням недели:
Отдельную политику включения можно настраивать для каждого пула виртуальных десктопов.
3. Client IP address auditing
Теперь можно просматривать детальную информацию обо всех сессиях, обслуживаемых брокером соединений: IP-адреса клиентов, время логина и логаута и другое.
4. Installation file
Теперь процесс развертывания Horizon Toolbox 2 идет в полноценном графическом интерфейсе.
5. Прочие улучшения
Производительность функций аудита была существенно повышения за счет оптимизации SQL-запросов.
Функция Remote assistance работает более стабильно.
Улучшена совместимость с различными версиями Horizon View.
Установщик на стороне пользователя проверяет, что режим Windows Remote Assistance настроен корректно.
VMware PowerCLI – это весьма мощный инструмент управления, а всё, что нужно сделать для начала работы с ним - это подключиться к серверу или серверам виртуальной инфраструктуры, которыми могут являться сервер управления vCenter Server, Linux vCenter Server Appliance (vCSA) или ESXi-хост.
В блоге VMware появился интересный пост о производительности СУБД Microsoft SQL Server на облачной платформе VMware vCloud Air. Целью исследования было выявить, каким образом увеличение числа процессоров и числа виртуальных машин сказываются на увеличении производительности баз данных, которые во многих случаях являются бизнес-критичными приложениями уровня Tier 1 на предприятии.
В качестве тестовой конфигурации использовались виртуальные машины с числом виртуальных процессоров (vCPU) от 4 до 16, с памятью от 8 до 32 ГБ на одну ВМ, а на хост-серверах запускалось от 1 до 4 виртуальных машин:
На физическом сервере было 2 восьмиядерных процессора (всего 16 CPU), то есть можно было запустить до 16 vCPU в режиме тестирования линейного роста производительности (Hyper-Threading не использовался).
В качестве приложения использовалась база данных MS SQL с типом нагрузки OLTP, а сами машины размещались на хостинге vCloud Air по модели Virtual Private Cloud (более подробно об этом мы писали вот тут). Для создания стрессовой нагрузки использовалась утилита DVD Store 2.1.
Первый эксперимент. Увеличиваем число четырехпроцессорных ВМ на хосте от 1 до 4 и смотрим за увеличением производительности, выраженной в OPM (Orders Per Minute), то есть числе небольших транзакций в минуту:
Как видно, производительность показывает вполне линейный рост с небольшим несущественным замедлением (до 10%).
Второй эксперимент. Увеличиваем число восьмипроцессорных ВМ с одной до двух:
Здесь также линейный рост.
Замеряем производительность 16-процессорной ВМ и сводим все данные воедино:
Проседание производительности ВМ с 16 vCPU обусловлено охватом процессорами ВМ нескольких NUMA-узлов, что дает некоторые потери (да и вообще при увеличении числа vCPU удельная производительность на процессор падает).
Но в целом, как при увеличении числа процессоров ВМ, так и при увеличении числа виртуальных машин на хосте, производительность растет вполне линейно, что говорит о хорошей масштабируемости Microsoft SQL Server в облаке vCloud Air.
Кстати, если хочется почитать заказуху про то, как облака VMware vCloud Air уделывают Microsoft Azure и Amazon AWS, можно пройти по этим ссылкам:
Осенью 2006 года я начал вести первый и на тот момент единственный на русском языке блог о виртуализации (понятное дело, тогда его никто еще не читал). Сначала это был небольшой бложек на движке Blogger, и посты были о каких-то настройках в VMware Workstaion. Того блога, как и первой версии сайта, уже давным давно нет, а портал VM Guru как самостоятельный ресурс оформился ровно 9 лет назад - 3 декабря 2006 года. Вот так он выглядел в далеком 2006 году:
С тех пор на нашем сайте появилось более трех с половиной тысяч записей, и сегодня это главный ресурс о виртуализации в России.
Трудно такое представить, но системные администраторы, которые сейчас управляют виртуальными инфраструктурами в свои 22 года, закончив институт, тогда еще ходили в 8-й класс. От всей души поздравляю всех авторов VM Guru и наших читателей с годовщиной!
Странные вещи происходят в последнее время с VMware. Сначала в технологии Changed Block Tracking (CBT) платформы VMware vSphere 6 был найдет серьезный баг, заключавшийся в том, что операции ввода-вывода, сделанные во время консолидации снапшота ВМ в процессе снятия резервной копии, могли быть потеряны. Из-за этого пользователи переполошились не на шутку, ведь бэкапы, а это критически важная составляющая инфраструктуры, могли оказаться невосстановимыми.
Недавно этот баг был пофикшен в обновлении ESXi600-201511401-BG, и вроде бы все стало окей. Но нет - оказалось, что накатить обновление на ваши серверы VMware ESXi недостаточно, о чем своевременно сообщила компания Veeam (официальная KB находится вот тут). Нужно еще и сделать операцию "CBT reset", то есть реинициализировать Changed Block Tracking для виртуальных машин.
Все дело в том, что уже созданные файлы CBT map могут содержать невалидные данные, касательно изменившихся блоков, а ведь они могли быть созданы еще до накатывания патча от VMware. Таким образом, простое обновление ESXi не убирает потенциальную проблему - старые файлы *-ctk.vmdk могут, по-прежнему, быть источником проблем. Удивительно, как такая могучая компания как VMware просто взяла и прошляпила этот момент.
Итак, как нужно делать CBT reset для виртуальной машины описано вот тут у Veeam. Приведем этот процесс вкратце:
1. Открываем настройки виртуальной машины (да-да, для каждой ВМ придется это делать) и идем в Configuration Parameters:
2. Там устанавливаем значение параметра:
ctkEnabled = false
3. Далее устанавливаем
scsi0:x.ctkEnabled также в значение false:
4. Открываем папку с виртуальной машиной через Datastore Browser и удаляем все файлы *-ctk.vmdk (это и есть CBT map файлы):
5. Включаем виртуальную машину и заново запускаем задачу резервного копирования Veeam Backup and Replication.
Для тех, кто умеет пользоваться интерфейсом PowerCLI есть бонус - компания Veeam сделала PowerShell-скрипт, который автоматизирует эту операцию. Он позволяет переинициализировать CBT для указанных пользователем виртуальных машин. Виртуальные машины со снапшотом, а также выключенные ВМ будут проигнорированы. Также надо отметить, что при выполнении сценария создается снапшот машины, а потом удаляется, что может вызвать временное "подвисание" машины и ее недоступность в течение некоторого времени, поэтому лучше выполнять этот скрипт ночью или в нерабочие часы.
Мы уже писали о том, что "растянутый" кластер VMware HA Stretched Cluster прекрасно работает и поддерживается вместе с отказоустойчивыми хранилищами Virtual SAN. Также мы писали о документе с лучшими практиками по построению таких кластеров, для которых требуется обеспечивать максимальную производительность.
Однако многие задаются вопросом - а как планировать ширину канала между площадками таких растянутых кластеров, чтобы обеспечить необходимую пропускную способность для синхронизации узлов кластера VMware Virtual SAN? В помощь таким пользователям компания VMware выпустила интересный документ "VMware Virtual SAN Stretched Cluster Bandwidth Sizing Guidance", в котором даются конкретные параметры и формулы для расчета необходимой пропускной способности между площадками.
Архитектура растянутого кластера в общем случае выглядит так:
Таким образом, имеет место быть 2 связи - между двумя площадками как узлами кластера, а также между каждой из площадок и компонентом Witness, следящим за состоянием каждой из площадок и предотвращающим сценарии Split Brain.
Для этих соединений рекомендуются следующие параметры:
Как известно, реальный трафик состоит из отношения операций чтения и записи, которое зависит от характера нагрузки. Например, в VDI-среде это отношение составляет примерно 30/70, то есть 30% - это операции чтения (read), а 70% - операции записи (write).
В среде растянутого кластера данные виртуальной машины всегда читаются с локальных узлов VSAN - это называется Read Locality. Ну а для операций записи, само собой, нужна определенная пропускная способность на другую площадку. Она рассчитывается как:
B = Wb * md * mr
где:
Wb - полоса записи данных.
md - множитель данных, он зависит от потока метаданных кластера VSAN и сервисных операций. VMware рекомендует использовать значение 1,4 для этого параметра.
mr - множитель ресинхронизации. Для целей ресинхронизации VMware рекомендует заложить в канал еще 25%, то есть использовать значение этого параметра 1,25.
Например, рабочая нагрузка у вас составляет 10 000 IOPS на запись (10 тысяч операций в секунду). Возьмем типичный размер операции записи в 4 КБ и получим параметр Wb:
Wb = 10 000 * 4KB = 40 MB/s = 320 Mbps
Мегабайты в секунду переводятся в мегабиты умножением на 8. Ну и заметим, что требование канала по записи нужно умножать на 1,4*1,25 = 1,75. То есть канал нужно закладывать почти в 2 раза больше от требований по записи данных.
Теперь считаем требуемую пропускную способность канала между площадками:
Компания VMware выпустила очень познавательный документ "An overview of VMware Virtual SAN caching algorithms", который может оказаться полезным всем тем, кто интересуется решением для создания программных хранилищ под виртуальные машины - VMware Virtual SAN. В документе описан механизм работы кэширования, который опирается на производительные SSD-диски в гибридной конфигурации серверов ESXi (то есть, SSD+HDD).
SSD-диски используются как Performance tier для каждой дисковой группы, то есть как ярус производительности, который преимущественно предназначен для обеспечения работы механизма кэширования на чтение (Read cache, RC). По умолчанию для этих целей используется 70% емкости SSD-накопителей, что экспериментально было определено компанией VMware как оптимальное соотношение.
SSD-диски значительно более производительны в плане IOPS (тысячи и десятки тысяч операций в секунду), поэтому их удобно использовать для кэширования. Это выгодно и с экономической точки зрения (доллары на IOPS), об этом в документе есть наглядная табличка:
То есть, вы можете купить диск SSD Intel S3700 на 100 ГБ за $200, который может выдавать до 45 000 IOPS, а это где-то $0,004 за IOPS. С другой же стороны, можно купить за те же $200 диск от Seagate на 1 ТБ, который будет выдавать всего 100 IOPS, что составит $2 на один IOPS.
Кэш на чтение (RC) логически разделен на "cache lines" емкостью 1 МБ. Это такая единица информации при работе с кэшем - именно такой минимальный объем на чтение и резервирование данных в памяти используется. Эта цифра была высчитана экспериментальным путем в исследовании нагрузок на дисковую подсистему в реальном мире, которое VMware предпочитает не раскрывать. Кстати, такой же величины объем блока в файловой системе VMFS 5.x.
Помимо обслуживания кэша на SSD, сервер VMware ESXi использует небольшой объем оперативной памяти (RAM) для поддержки горячего кэша обслуживания этих самых cache lines. Он содержит несколько самых последних использованных cache lines, а его объем зависит от доступной памяти в системе.
Также в памяти хранятся некоторые метаданные, включая логические адреса cache lines, валидные и невалидные регионы кэша, информация о сроке хранения данных в кэше и прочее. Все эти данные постоянно хранятся в памяти в сжатом виде и никогда не попадают в своп. При перезагрузке или выключении/включении хоста кэш нужно прогревать заново.
Итак, как именно работает кэширование на SSD в VMware Virtual SAN:
1. Когда операция чтения приходит к Virtual SAN, сразу же включается механизм определения того, находятся ли соответствующие данные в кэше или нет. При этом запрашиваемые данные за одну операцию могут быть больше одной cache line.
2. Если данные или их часть не находятся в RC, то для них резервируется буфер нужного объема с гранулярностью 1 МБ (под нужное количество cache lines).
3. Новые аллоцированные cache lines вытесняют из кэша старые в соответствии с алгоритмом Adaptive Replacement Cache (ARC), который был лицензирован VMware у IBM.
4. В случае промаха кэша каждое чтение одной cache line с HDD разбивается на чанки размером 64 КБ (этот размер тоже был определен экспериментально в ходе исследований). Это сделано для того, чтобы не забивать очередь на чтение с HDD "жирной" операцией чтения в 1 МБ, которая бы затормозила общий процесс ввода-вывода на диск.
5. В общем случае, одна операция чтения запрашивает лишь часть данных одной cache line, а первыми читаются именно нужные 64 КБ чанки с HDD-диска от этой cache line.
6. Запрошенные с HDD-диска данные сразу отдаются к подсистеме вывода и направляются туда, откуда их запросили, а уже потом в асинхронном режиме они попадают в соответствующие cache lines кэша и под каждую из них выделяется буфер 1 МБ в памяти. Таким образом устраняются потенциальные затыки в производительности.
В документе описаны также и механики работы кэша на запись (Write cache), для которого используется техника write-back, а также рассматриваются All Flash конфигурации. Читайте - это интересно!
Компания VMware на днях представила проект VMware Sample Exchange, представляющий собой портал, где разработчики выкладывают для загрузки различные шаблоны сценариев, помогающие в решении повседневных задач по администрированию виртуальной инфраструктуры VMware vSphere.
На этом сайте можно найти не только сценарии сотрудников VMware на языках/оболочках PowerShell/PowerCLI, Python, Ruby, Java и других, но и предложить свой вариант решения задачи или запросить его у сообщества профессионалов, которые будут там тусоваться (потому и называется Exchange). На данный момент на портале есть контент от таких известных многим людей, как Alan Renouf и William Lam.
Сейчас загружать свой контент и сценарии могут только носители звания VMware vExpert и авторизованные со стороны VMware люди, но в релизной версии сервиса это смогут сделать все желающие (на данный момент обсуждения по этим вопросам находятся вот тут).
В левой колонке портала находятся фильтры по категориям применения сценариев (платформы, решения VMware и бизнес-задачи):
А также по языку программирования/интерфейсу:
Пока в библиотеке всего 260 сэмплов (нераспиханных по категориям и интерфейсам), но будем надеяться, что скоро коллекция существенно расширится и там наведут порядок.
Сегодняшняя статья расскажет вам ещё об одной функции моего PowerShell-модуля для управления виртуальной инфраструктурой VMware - Vi-Module. Первая статья этой серии с описанием самого модуля находится здесь. Функция Convert-VmdkThin2EZThick. Как вы уже поняли из её названия, функция конвертирует все «тонкие» (Thin Provision) виртуальные диски виртуальной машины в диски типа Thick Provision Eager Zeroed.
Многие из вас знают утилиту esxtop (о которой мы часто пишем), позволяющей осуществлять мониторинг производительности сервера VMware ESXi в различных аспектах - процессорные ресурсы, хранилища и сети. Многие администраторы пользуются ей как раз для того, чтобы решать проблемы производительности.
Но оказывается, что использование esxtop само по себе может тормозить работу сервера VMware ESXi!
Это может произойти в ситуации, если у вас к ESXi смонтировано довольно много логических томов LUN, на обнаружение которых требуется более 5 секунд. Дело в том, что esxtop каждые 5 секунд повторно инициализирует объекты, с которых собирает метрики производительности. В случае с инициализацией LUN, которая занимает длительное время, запросы на инициализацию томов будут складываться в очередь. А как следствие (при большом числе томов) это будет приводить к возрастанию нагрузки на CPU и торможению - как вывода esxtop, так и к замедлению работы сервера в целом.
Выход здесь простой - надо использовать esxtop с параметром -l:
# esxtop -l
В этом случае данная утилита ограничит сбор метрик производительности только теми объектами, которые были обнаружены при первом сканировании. Соответственно, так лучше всего ее и использовать, если у вас к серверу VMware ESXi прицеплено много хранилищ.
Как и другие документы этой серии, этот whitepaper богат различными графиками и диаграммами, касающимися производительности решения. Например, вот производительность обычного кластера VMware Virtual SAN 6.1 и растянутого с задержками (latency) в 1 мс и 5 мс:
Основные моменты, раскрываемые в документе:
Развертывание и настройка Virtual SAN Stretched Cluster
Производительность растянутого кластера в сравнении с обычным
Производительность кластера при различных отказах (хост, сайт целиком)
Лучшие практики использования растянутых кластеров
Некоторое время назад вышло обновление VMware vSphere 6.0 Update 1, после чего пользователи Onyx под Web Client заметили, что он перестал работать. Напомним, что Onyx предназначен для записи действий пользователя в клиенте vSphere, после чего они записываются в виде сценариев PowerShell.
Теперь в обновленном Onyx для VMware vSphere Web Client, который можно скачать с сайта VMware Labs, новая версия vSphere 6.0 U1 полностью поддерживается.
Причина плохого поведения Onyx проста - так как этот продукт теперь полностью завязан на VMware vCenter, то теперь любое значимое изменение оного требует отдельного апдейта.
Таги: VMware, Onyx, Update, Labs, vSphere, Web Client, PowerShell, PowerCLI
RSS
